Profile picture

[Ansible] Ansible, 왜 엉뚱한 계정으로 접속을 시도할까요?

JaehyoJJAng2024년 05월 25일

앤서블! 왜 로그인된 계정으로 접속을 시도할까요?

Ansible을 설치하고, 설레는 마음으로 관리 서버들과의 연결을 확인하기 위해 첫 명령어를 날려봅니다!

ansible all -m ping

그런데 우리를 반겨주는 것은 초록색 SUCCESS가 아닌, 빨간색 UNREACHABLE 메시지일 때가 있습니다.


제 경우에는 다음과 같은 메시지가 보이네요.

192.168.219.121 | UNREACHABLE! => {

"changed": false,

"msg": "Failed to connect to the host via ssh: Warning: Permanently added '192.168.219.121' (ED25519) to the list of known hosts.\r\nansible-master@192.168.219.121: Permission denied (publickey,password).",

"unreachable": true

}

분명 관리 노드(192.168.219.121)의 접속 계정은 ansible-node1인데, 왜 자꾸 제어 노드(마스터 서버)의 계정(ansible-master)으로 접속을 시도하다가 권한 오류가 발생하는걸까요?


오늘은 이 당황스러운 오류의 원인과 해결책, 그리고 앤서블을 더 '앤서블답게' 사용하는 전문가 팁까지 쉽고 명확하게 기록해보려고 합니다.


이유: 앤서블은 SSH의 규칙을 그대로 따릅니다.

결론부터 말하자면, 앤서블의 이런 동작은 오류가 아니라 지극히 정상적인 기본 동작입니다.

그 이유는 바로 '단순함'과 '일관성' 에 있습니다.


앤서블은 복잡한 자체 통신 프로토콜 대신, 우리에게 매우 익숙한 SSH 를 기반으로 동작합니다.

따라서 앤서블의 기본 접속 방식은 표준 SSH의 규칙을 그대로 따르죠.


터미널에서 다른 서버로 SSH 접속을 시도하는 상황을 떠올려 볼까요?

# 'ansible-master' 계정으로 로그인된 서버에서 아래 명령을 실행하면?
ssh 192.168.219.121

위와 같이 접속하려는 사용자 이름을 명시하지 않으면,

SSH는 현재 로그인된 사용자의 계정(ansible-master) 으로 192.168.219.121 서버에 접속을 시도합니다.


너무나 당연한 SSH의 규칙이죠.


앤서블도 마찬가지입니다.

우리가 별다른 설정을 하지 않으면, 명령을 실행하는 현재 사용자 계정으로 모든 관리 노드에 접속을 시도하는 것이죠.


해결책: 원격 사용자를 명확히 알려줍시다!

이제 원인을 알았으니 해결 방법은 너무나도 간단합니다.

앤서블 인벤토리 파일(/etc/ansible/hosts)에 접속하려는 호스트와 사용할 계정을 명확하게 알려주면 됩니다!


이때 사용하는 변수가 바로 ansible_user 입니다.

# /etc/ansible/hosts

[all]
# IP 주소 뒤에 어떤 계정을 사용할지 명시해줍니다.
192.168.219.121 ansible_user=ansible-node1

이렇게 수정하고 다시 ping 테스트를 해보면,

앤서블은 192.168.219.121에 접속할 때 ansible-node1 계정을 사용하게 되어 깔끔한 성공 메시지를 보게 될겁니다.


잠깐, 그럼 제어 노드에서 root로 실행하면 편하지 않을까요?

이런 궁금증이 생길 수 있습니다. "어차피 관리 노드에서 root 권한 작업도 해야 하니, 그냥 제어 노드에서 root 계정으로 앤서블을 실행하면 편하지 않을까?"


결론부터 말씀드리면, 전혀 그렇지 않으며 매우 위험한 발상입니다.

실무 환경에서는 보안상의 이유로 절대 권장되지 않습니다.


최소 권한의 원칙 위배

root는 모든 것을 파괴할 수 있는 절대반지입니다. 제어 노드의 root 계정이 실수나 해킹으로 탈취되면, 연결된 모든 서버가 한 번에 장악되는 끔찍한 재앙으로 이어질 수 있습니다.


감사 및 추적의 어려움

모든 작업을 root가 수행하면, 나중에 문제가 발생했을 때 어떤 변경이 '누구' 또는 '어떤 자동화 프로세스'에 의해 이루어졌는지 추적하기가 매우 어렵습니다.


앤서블의 정석: 필요할 때만 관리자로! become

그렇다면 패키지 설치나 서비스 재시작처럼 root 권한이 필요한 작업은 어떻게 할까요?

바로 이럴 때를 위해 앤서블의 핵심 기능인 권한 상승(Privilege Escalation), become 이 존재합니다.


become은 평소에는 일반 계정(ansible-node1)으로 서버에 접속해 작업을 수행하다가,

root 권한이 필요한 특정 작업을 만났을 때만 sudo 명령을 통해 잠시 관리자 권한을 빌려와 작업을 수행하게 만드는 우아한 기능입니다.


플레이북 예시

---
- name: Nginx 웹서버 설치 및 실행
  hosts: all
  tasks:
    - name: nginx 최신 버전 설치
      apt:
        name: nginx
        state: latest
      become: yes  # <-- 이 작업을 실행할 때만 sudo를 통해 root 권한을 획득!

    - name: nginx 서비스 시작
      service:
        name: nginx
        state: started
      become: yes  # <-- 이 작업도 root 권한이 필요하므로 become 사용!
    Tag -
Loading script...